A cellular mobile access network is a radio network made up of a number of cells, each cell being served by a fixed transmitter. Cells are used to cover different areas in order to provide radio coverage over a wider area than the area of one cell.
As shown in FIG. 1, when a user with mobile equipment 101 moves between the areas covered by adjacent cells 102, 103, a handover must be performed between those cells. A connection between the mobile equipment 101 and the old cell 102 is broken, and a new connection between the mobile equipment 1 and a new cell 3 is established. The cells may comprise a Base Station, Radio Network Controller, or other similar device that has a downlink buffer. Data held in the downlink buffer at the old cell 102 must be transferred to the downlink buffer of the new cell 103.
In 3G networks, this is solved by a special procedure and signalling standardized by 3GPP. In current 3G networks the buffer transfer procedure is done infrequently only when the user moves between Radio Network Controllers (RNCs). In future Long Term Evolution (LTE) technology, it is planned that this procedure will be done frequently because the packets are stored in the Base Stations (BSs) 104, 105, as illustrated in FIG. 1, and will therefore be transferred between base stations during cell handover.
In mobile networks, when a cell change occurs, a buffer transfer may be required between the buffers of the involved base stations. Of course, the faster the transfer of buffer data between cells, the better and more “seamless” the user's experience will be. Possible solution for transferring data held in a buffer include possible solutions include User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), but there are problems with using either of these protocols. Transport links will typically be shared between several base-station-to-base-station or base-station-to-anchor, etc. connections. Data traffic over the shared links may arrive from many different sources. It is therefore difficult to estimate the available capacity for a buffer transfer.
The easiest solution is to use standard UDP and burst the data to the target base station at a high rate. Unfortunately the correct rate of this burst is unknown and if it is not estimated correctly, there may be many losses in the transfer. Furthermore, this technique may cause congestion for other connections sharing the same path. If for example, the error in the available rate estimation is just 10%, it will cause approximately 10% loss for the transmitted buffer data. This is a high amount for end-user applications, and is very detrimental to the performance as perceived by the end-user.
TCP, Stream Control Transmission Protocol (SCTP), or custom congestion-controlled UDP may solve the problem of sending buffer data at too high a rate, but these protocols require a large data overhead, making them inefficient for transferring buffer data. To establish a TCP connection takes too long a time (at least 2 round-trip times are needed before the actual buffer data can be sent). Furthermore. TCP requires a slow-start in order to reach the correct rate of data transfer. The result is that the handover interruption time would be dominated by such overheads and not radio protocols. The time required to set up a connection and speed up data transfer to the available rate is between 28-535 ms, which is too large considering that the radio interruption should be of a shorter time.
An alternative solution is to use pre-established connections to save connection setup time. Keep-alive SCTP, TCP or custom congestion-controlled UDP solves the problem of the connection setup overhead, but when there is no data traffic for a period of time, assumptions made by these protocols about congestion is invalid and not within a guaranteed precision e.g., 10%. An implication of this is that there may be insufficient available capacity and packets may need to be re-transmitted, possibly causing long time-out and a slow-start. Furthermore, the Internet Engineering Task Force (IETF) suggests that if there is no traffic, the congestion window of TCP should be reduced to avoid overloading the available data paths. Again, this leads to the problem that a certain time needed to test for capacity starting from a low data transfer rate.
As shown in FIG. 2, using a TCP tunnel-based solution in a wireless emulation testbed shows that the speed of data transfer slows down considerably during handover, even though the radio handover time was set to zero ms (the data shown assumes a Round Trip Time, RTT, of 200 ms, and a transfer rate of 5 Mbps). The x-axis shows time and the y-axis shows cumulative number of bytes transmitted. It can be seen that the slow-down lasts for around 2 seconds The reason for the approximately 2 sec slow-down is that the transfer tunnel needs to test the available capacity to avoid Node-B-to-Node-B transport congestion.